✅ Deploy Preview for mermaid-js ready!

Name	Link
🔨 Latest commit	2455af1
🔍 Latest deploy log	https://app.netlify.com/sites/mermaid-js/deploys/66a3d11dfbc04100080bc446
😎 Deploy Preview	https://deploy-preview-5650--mermaid-js.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Codecov Report

Attention: Patch coverage is 0% with 22 lines in your changes missing coverage. Please review.

Project coverage is 5.85%. Comparing base (c0bf6d8) to head (2455af1).
Report is 1166 commits behind head on develop.

@@            Coverage Diff             @@
##           develop   #5650      +/-   ##
==========================================
- Coverage     5.85%   5.85%   -0.01%     
==========================================
  Files          274     274              
  Lines        41112   41132      +20     
  Branches       488     488              
==========================================
  Hits          2408    2408              
- Misses       38704   38724      +20     

The latest updates on your projects. Learn more about Argos notifications ↗︎

@sidharthv96 here's a preview

@cmnstmntmn This kinda breaks the simplicity we had with the :::animate class. The current approach adds more control, but feels clunkier. Also, the producer, consumer classes might be common and could interfere with existing diagrams.

We should brainstorm to find a way to select individual edges if possible.

I really love the simplicity of the current syntax. So maybe we can keep that, and add something to make individual edges animated in a later release.

What if, we add :::animate to both sides (node) of an edge, instead of producer and consumer? It will take away a bit of control, but the syntax is easier to remember.

Just to be clear, I want your opinion on this, please don't write code 😅, we can discuss and finalise an approach and then write code. 😇

graph LR
A:::animate -.-> B:::animate -.-> A -.-> C

And maybe if we play around with the parsing a bit, we might be able to isolate just the edge that needs to be animated. I can help with that part.

yeap, having .animate on both ends seems easier and more generic

Hello! Thanks @cmnstmntmn for pitching in!
There is a general problem with edges in Mermaid. Using the current syntax, you cannot assign an ID to the actual edge. You need an ID to be able to play styling/classes to the specific edge at later statements.

This has led us to use the order of appearance for applying styles to edges. This approach comes with its own set of problems. If you introduce a new edge that can shuffle styling around, this approach could be used for animation as well.

In your example, @sidharthv96, with classes applied to both nodes as selectors, we will run into trouble when there is more than one edge and we want to apply the style to one of the edges.

I think it is time to solve this more robustly. I suggest that we introduce a way to attach an ID to an edge using the syntax itself without relying on work-arounds.

I am not saying this change needs to be done in this PR, but it should be the way to select an edge for styling.

Some spitballing - It could look something like this:

...
C{"Evaluate"} -- One {id: one} --> D

Where the label ends with the id statement we set the id of the label in the db when creating the label. Then we can use the class statement perhaps:

class one animate

We could also allow classes directly in the id statement:

...
C{"Evaluate"} -- One {id: one, class: animate} --> D

would work with style statements as well:

linkStyle one stroke:#2962FF
%% same thing as below but without the risk of reshuffling
linkStyle 0 stroke:#2962FF

We need to think through the actual syntax in the edge label, as once we introduce it, we are stuck with it. My own objection to {id: one, class: animate} is that it looks very similar to a decision making the diagram harder to read. Something along those lines would be good though.